home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000354_news@columbia.edu _Wed Jul 3 10:24:22 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id KAA24679 for <kermit.misc@watsun.cc.columbia.edu>; Wed, 3 Jul 1996 10:24:22 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id KAA16698 for kermit.misc@watsun; Wed, 3 Jul 1996 10:24:19 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: file transfer
  8. Date: 3 Jul 1996 14:24:15 GMT
  9. Organization: Columbia University
  10. Lines: 40
  11. Message-ID: <4rdvqf$g9n@apakabar.cc.columbia.edu>
  12. References: <omafxh7spj.fsf@tees.cs.ualberta.ca>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14.  
  15. In article <omafxh7spj.fsf@tees.cs.ualberta.ca>,
  16. Vladimir Alexiev  <vladimir@cs.ualberta.ca> wrote:
  17. : While I transfer from C-Kermit 5A(190) to DOS MS-Kermit 3.14, I notice that
  18. : the packet size oscillates up and down from the initial 9000 to as low as
  19. : 17. This makes so that more than half of the traffic is protocol, not data.
  20. : I don't think the phone line is that bad, and I use a Supra V32bis 14.4
  21. : with LAPM and MNP5. The kermit parameters I use are:
  22. : 
  23. : set baud 38400   ; my files are zipped, so this should be enough
  24. : set flow-control rts/cts
  25. : set block-check 3                       ; 16-bit CRC
  26. : set windows 5
  27. : set receive packet 9000
  28. : set send packet 9000
  29. : set control unprefixed all
  30. : set control prefixed 0 1 3 13 129 131 141
  31. : 
  32. : What can I do to speed this up?
  33. :
  34. You are failing to be properly amazed that your transfers work at all :-)
  35. Kermit reduces its packet length automatically when there is an
  36. error.  A very common cause of errors when you are using long packets is
  37. buffer overruns which, in turn, are caused by a lack of adequate flow
  38. control (are you sure the modem is set for RTS/CTS too?) and/or hardware
  39. problems -- for example, if you have an unbuffered UART and it is generating
  40. interrupts faster than the CPU can service them.  No amount of error
  41. correction in the modem will do any good in a case like this, because the
  42. errors are occurring outside the modem-to-modem connection.  Similar types
  43. of errors can be caused by other processes (including TSRs) that grab CPU
  44. cycles away from Kermit or, worse, turn off interrupts now and then.
  45.  
  46. So Kermit automatically reduces the packet length in order to minimize the
  47. chance of buffer overruns.  Like when you take your Jeep off the road and
  48. put it into 4-wheel drive and first gear to go up a steep bumpy mountain
  49. path.
  50.  
  51. Read the KERMIT.BWR file that comes with MS-DOS Kermit 3.14 -- it talks about
  52. all of these problems in great detail.
  53.  
  54. - Frank